多團隊在一起開發會遇到什麼問題呢? 這件事情我們要先搞清楚, 因為沒有問題就沒有需求. 看它能夠處理多少問題, 或者是它能夠處理哪些問題, 這將會成為我們選擇大規模敏捷框架的標準, 或者決定大規模敏捷框架的好壞.

以下是多團隊一起開發常見的問題：

(1) 同時間要處理多個專案

通常有多團隊一起合作開發, 可能的是針對要處理某個複雜性高的產品或專案. 但是最後通常都會演變成要處理多個產品或專案, 因為你的團隊很大, 老闆覺得你是可以處理多件事情的, 否則你養這麼多人要幹嘛.

但是這樣會帶來很多問題. 首先, 不同的產品或專案, 就會有多需求來源, 那這時候到底要哪一個先做, 這個問題通常是讓團隊成員感到最痛苦的, 因為他們只擅長處理工程面的問題, 對於管理面的問題他們往往覺得不知所措, 怎樣安排才能面面俱到.

這時候可能是喊最大聲的人, 會最先幫他做. 或者是團隊挑自己喜歡的先做. 但是這樣的安排是否能夠讓公司獲利最大, 是否能夠讓客戶滿意, 往往不是最先的考量.

(2) 資源分配不均

在開發的過程中, 也許剛開始的時候團隊 A 負責的事情比較重要, 所以我們分配給他比較多人, 一段時間之後, 團隊 B 所負責的事情變成比較重要, 那這時候該怎麼辦, 幫團隊 B 加人嗎? 如果這樣做會導致公司整體人數越來越多. 如果選擇不加人, 就會需要跟別的團隊調人來支援, 可是如果沒有上層管理者的支持, 大多別的部門是不會來支援的. 就算有上層管理者的幫助, 別的部門主管也可能使絆子, 例如給你菜鳥或是績效不佳的員工, 對你的幫助其實也很有限.

(3) 每次所需技能不同

每次開發時每個功能所會用的技能可能不同, 有時候我們需要會 C++的人選, 有時候我們會需要 Java 的人選. 這會跟你的系統所使用的技能有關.

或許你可能會盡量統一所使用的語言, 讓大多系統都是使用相同的開發語言. 但是你還是可能會遇到前端開發和後端開發的差異, 這次可能前端工作比較多, 下次可能後端工作會比較多.

不管你是上述哪種狀況, 你不太可能每次遇到時, 相對應技能的人都是足夠的, 這時候就可能造成有些人在那當下沒有事做, 或是沒有太多事做, 你可能會覺得是個浪費, 更重要的是那些剛好忙的技能的人, 你也沒辦法幫太多忙, 導致每次都會有瓶頸發生.

(4) 組織依技術拆分

很多時候我們會系統架構或是技術來組成團隊. 像是前端團隊, 後端團隊. 或者是 iOS團隊, Android 團隊. 這樣切分好處是工程師就是專心某種技能, 學習比較容易, 並且效能可以達到最高. 這樣的想法是從工業時代泰勒的科學管理理論所來的, 他將工作拆分成均等的小塊, 每個工人就是負責一小塊, 因此在訓練的時候只要針對某項技能去訓練, 工人會比較容易學會, 並且也容易精通, 精通後效能自然可以提昇.

可是這時候問題來了, 當客戶回報某個功能不能運作, 每個團隊都說這不是他的問題, 因為功能和元件或技術之間並沒有直接的關聯, 除非被抓到明顯的正確, 否則不會有人出來認領. 即時一開始被抓到, 在查問題的過程也會極力證明自己沒問題, 問題是別人所帶來的, 至於客戶的問題何時被解, 或是客戶滿不滿意這件事, 可能不見得在他考量當中.

(5) 需要等待別的團隊

因為多團隊一起開發某些東西, 你可能會期待整理出互相獨立的工作, 大家各做各的. 或者是有簡單的關聯, 大家只要一開始就講好, 然後最後找個時間整合一下, 這樣工作就可以完成. 但是以小弟這麼多年的工作經驗, 以及和各位朋友交流後的感想, 目前應該是找不到這樣的情況, 或者是有這樣的理論出現.

因此, 常遇到的是需要和別的團隊頻繁討論和整合去解決. 可是每個團隊規劃的計畫不同, 不見得彼此能配合得上. 就算事先雙方先討論好同步的計畫, 但有時候計畫畢竟是計畫, 總是會有不準的時候, 因此等待是一件無法避免的事, 這時候團隊就會在那邊空轉.

(6) 不清楚別的團隊在做什麼

當團隊人數一多, 通常就不容易知道別人在做些什麼. 這個到團隊之中情況更是嚴重. 那這會有什麼問題呢? 首先, 大家可能各自開發重複的東西. 有些小工具或是模組, 可能大家都會用到, 因為沒有溝通大家就自己開幹, 導致類似的東西在很多地方都出現, 或者會有些地方有點像卻又不太一樣.

第二需求會各自解讀. 對某些需求的處理, 因為雙方可能個各自負責一部分, 但是因為沒有溝通, 或是充分或即時的溝通, 導致做出來的東西不是同一個東西. 就像高架橋從兩邊建起來, 到最後要整合的時候兩邊連不起來.

第三相同的問題會重複解. 有些開發的問題每個團隊都會遇到, 像是某些問題的架構設計, 自動化測試框架的選擇, 或者是 Sprint Review 的進行方式等等, 每個團隊可能都自己經歷過一次, 雖然親自做過一次印象比較深刻, 如果成果是好也就算了. 但往往是有一個可以成功就不錯, 大多都是花了時間卻沒有很的結果發生.

第四地方派系. 當你越少溝通時, 大家就越會以自己團隊為主, 而不認為我們是同一個大的團隊. 這樣會讓大家向心力降低, 遇到事情時也不會互相幫助.

(7) 團隊只做他擅長的東西

多個團隊在分工時, 往往常見的現象是每個團隊只拿他擅長的, 這樣做起來最快. 老闆同樣也會這樣想, 在時程的壓力下, 他也不敢把工作分配給不懂的團隊. 在這樣的思維下, 可能某個團隊就會固定做某些功能的事情, 這樣的效率會最高, 但是可能導致這個團隊長遠下來只會這件事情. 如果這個功能或技術會一直紅的話, 那也不是太大的問題, 但是以資訊業快速演進的狀況, 有可能幾年後這個東西是過時的, 到時候這些人可能就會面臨失業或是被打散到其他團隊中.

另外, 在分工時也不見得剛好都有這個團隊擅長的事做, 這個團隊也可能空轉, 或者是裝忙, 讓別人以為他們也是很有事做的.

(8) 開會溝通的時間變長

當團隊變多和人變之後, 自然需要溝通的時間也變多. 你不可能不花時間溝通就通靈了解需求是什麼, 對方的設計是什麼. 但是感覺這樣的時間似乎要花很多, 會不會已經耽誤到原先開發的時間. 有沒有什麼機制讓溝通可以有效率, 讓時間可以花在刀口上面.

(9) 組織角色越來越複雜

當團隊變多時, 有些公司會新增一些角色, 協調個團隊之間的工作, 或者是確認大家是否按照原先計劃的去做. 例如你要將工作分配給這些團隊去做, 就是有人要去規劃分配. 當大家各自領去做事, 也要誘人確認大家整合起來是否正常. 另外, 也許有人要去管理把完成的功能上類產品的環境 (staging) 或是產品環境 (production), 看看上去之後是否對於現存環境是否有影響.
因此, 你將會有不少角色增加, 也讓你更搞不清楚大家在做什麼. 公司也要請更多人. 萬一這個部門縮減時, 這些角色的處理也是件麻煩的事情.

以上就是多團隊一起開發常見問題的描述. 日後你在選擇大規模敏捷框架, 可以來思考一下他們的解法擅長處理什麼問題, 是否能夠將上述問題都解決或是舒緩. 還是更惡化上面這些問題.